1. Field of the Invention
The invention relates to cached security data. Specifically, the invention relates to apparatus, systems, and methods for sharing a cached security profile in a database environment.
2. Description of the Related Art
Large scale database management systems (LSDBMS), such as IBM's Information Management System (IMS), often have unique operating requirements. For example, these systems should service large volumes of transactions almost simultaneously. Transactions should complete as quickly as possible. Although many thousands of users may be using the LSDBMS at any given time, each transaction should be authenticated to ensure security of the data. The LSDBMS should operate 24/7 with any down time kept to an absolute minimum. Large corporations and other entities invest heavily in the speed, reliability, and security provided by these LSDBMS.
Data maintained by LSDBMSs is often very critical to the owner of the LSDBMS and/or the user. Consequently, certain transactions may authenticate a user's identity and authority multiple times to perform a transaction or parts of the transaction. Such authentication is known as authorization checking. Authorization checking should be done rapidly to minimize delay in completing the transaction.
FIG. 1 illustrates a conventional system 100 configured to rapidly perform authorization checking. The system 100 includes a client application 102, a network 104, and a LSDBMS 106, such as IMS 106. Generally, IMS 106 operates on a server 108 such as a mainframe. The server 108 may execute various operating systems, such as Multiple Virtual Storage (MVS), OS/390, or zSeries/Operating System (z/OS).
The client application 102 may comprise a web-based client, a terminal device, or any other software module configured to execute transactions on the IMS 106. The client 102 sends a transaction request over the network 104. The network 104 may comprise direct terminal connections, a Local Area Network (LAN), the Internet, or the like. IMS 106 executes the transaction and provides a result to the client application 102.
Generally, each transaction requires authorization checking to ensure security of the data. Authorization checking involves reading a security profile (SP) 110 uniquely associated with the user initiating the transaction. Typically, the SP 110 includes information identifying the user and the types of transactions the user is allowed to execute. If the user is identified and authorized according to the SP 110 to execute the transaction, the transaction is allowed to execute. Otherwise, the transaction request is rejected.
Initially, when a user requests a transaction, the SP 110 is loaded from database files 112 maintained by a security software component of server 100 such as the Resource Access Control Facility (RACF) from IBM. Loading the SP 110 incurs I/O overhead as the SP 110 is read from comparatively slow storage devices such as disk drives.
As mentioned above, a single transaction may require multiple authorization checks. In addition, a user of the client application 102 may initiate a series of separate transactions within a relatively short time period. Consequently, to prevent I/O overhead for each transaction, the SP 110 is temporarily stored in a cache 114.
Typically to meet performance objectives, transactions are executed by one or more independent modules in IMS 106. Generally, a transaction request is received by an initial module 116. The initial module 116 typically performs an authorization check using the a cached SP 110. If the SP 110 for a particular user is not cached, the initial module 116 caches the SP 110. If the authorization check is successful, the transaction is queued for execution by a secondary module 118.
In certain circumstances, the secondary module 118 also performs an authorization check. For example, an authorization check may be performed by the secondary module 118 prior to initiating a program switch to complete the transaction. Similarly, the secondary module 118 uses a cached SP 110 for the authorization check, if possible.
Cached SPs 110 should be refreshed periodically to ensure that the most recent data in an SP 110 is used to satisfy authorization checking requests. Consequently, each transaction request received by IMS 106 includes an aging value. The aging value defines a period of time for which the SP 110 is valid in the cache 114. If an initial module 116 or secondary module 118 determines that an SP 110 is as old as, or older than the aging value, the current SP 110 in the cache is deleted and a new version of the SP 110 is loaded.
In addition, to provide security in an emergency situation, the IMS 106 permits a database administrator to force transactions to use only the most recent version of SP 110 for one or more users stored in the database files 112. Typically, the database administrator issues a refresh request message. Consequently, any cached SPs 110 are deleted from the cache 114 by the initial module 116 or secondary module 118 when the next request for a cached SP 110 is made.
Preferably, the initial module 116 and secondary module 118 function asynchronously. Unfortunately, because both modules 116, 118 share access to a single cached SP 110 and are capable of deleting and loading a new version of the cached SP 110, there is a high potential for data inconsistency. For example, both the initial module 116 and secondary module 118 may attempt to use the same SP 110 at substantially the same time. Alternatively, one module, the initial module 116 for example, may delete the SP 110 based on the existing aging value prior to the secondary module 118 having an opportunity to use the SP 110 in an authorization check. The secondary module 118 does not know the particular SP 110 was just deleted. When the secondary module 118 uses the particular SP 110 for an authorization check, the secondary module may experience an error due to the attempt to use the deleted SP 110.
One potential solution is to use a latching or locking methodology for the SPs 110. However, due to the speed at which transactions are processed in the IMS 106, even a momentary delay for one module 116 to release a lock on an SP 110 is unacceptable. Furthermore, avoiding or resolving deadlock conditions between the modules 116, 118 regarding the SP 110 adds additional unacceptable complexity and delay. In addition, latching or locking methodologies do not adequately address responding to an administrator initiated refresh request.
Accordingly, what is needed is an apparatus, system, and method for sharing a cached security profile in a database environment. The apparatus, system, and method should maintain data consistency for cached security profiles without significantly increasing cache management overhead. In addition, the apparatus, system, and method should serialize access by one or more modules to a cached security profile without requiring that the security profile be locked or latched during an authorization check. The apparatus, system, and method should also allow for administrator initiated refresh requests.